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ABSTRACT 


An appraisal of whether to improve the existing multi-laser/ 
multi-detector system was undertaken. This Involved studying two 
features of the elevation scanning mast which prevent the system from 
meeting desired specifications. These features are: first, the 

elevation scanning mast has 20 detectors, as opposed to the desired 
40. This influences the system's overall resolution. Second, the 
mirror shaft encoder's finite resolution prevents the laser from being 
aimed exactly as desired. This influences the system’s overall accuracy. 
A study of these two features led to a proposal to not modify the 
existing system at present. 

Also undertaken was the design and construction of a Data 
Emulator. This device, which allowed testing data transactions with a 
PRIME computer, is described, and theory of operation briefly discussed. 
After testing and debugging this device, a full blown PRIME/Rover Inter- 
face was designed and built. The capabilities of this Interface are 
described and its operating principles briefly discussed. 
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INTRODUCTION 

1.1 History 

In 1957 the space age was launched with the Sputnik. Ten 
years later R.P.I, became Involved in the space exploration effort. 

In a project jointly funded by NASA and the Jet Propulsion Labs, 

R.P.I. began studying various problems associated with the unmanned 
exploration of Mars. In 1973 attention was directed toward designing 
and constructing a one-half scale prototype Mars Roving Vehicle (see 
Figure 1.1). This vehicle (‘Rover’) would carry an on-board labora- 
tory and must be able to visit a number of sites. 

R.P.I. 's research efforts are focused on the topic of 
obstacle detection and avoidance. In traversing from site to site, 
the Rover must be able to detect and avoid obstacles on an unknown 
terrain. One might guess that the vehicle could be radio controlled 
from earth. This is impractical because the round trip radio- 
communication time to Mars ranges from nine to 45 minutes. Instead of 
being directly controlled from earth, the vehicle would be an Autonomous 
Mars Roving Vehicle. The heading of the vehicle to a site of interest 
could be selected by earth-based researchers on the basis of pictures of 
the Martian terrain. A computer on board the Rover would select its 
path around obstacles as it made its way to that site. 

By 1977 the prototype 'Rover' had been constructed. It 
featured an on-board hazard detection system, and was operated under 
the control of the Varian 620i minicomputer via a radio link. 
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RENSSELAER AUTONOMOUS ROVING VEHICLE 
Figure 1.1 





Hazard detection was accomplished mi ng a simple laser tri- 
angulation concept (see Figure 1.2). A laser was fired toward level 
ground at 15 evenly spaced azimuths over an arc of 140* (see Figure 1.3). 
A detector was also aligned and aimed such that on level ground the 
detectors would always receive reflected light from each laser shot 
(see Figure 1.4). Any unknown terrain which passed through the de- 
tector's cone of vision and reflected a laser shot into the detector 
was considered safe. A terrain-laser intersection point falling out- 
side the detector's cone of vision. would go undetected (see Figure 1.4). 
This terrain was considered unsafe. Using this concept one was able to 
distinguish between safe and unsafe terrain on the basis of returns 
from laser shots. 

An advantage of this system over several alternate schemes is 
its ability to detect negative obstacles. A problem with it is that it 
tends to be a conservative system. By this we mean that it judges some 
terrain features to be 'unsafe', when in reality they are 'safe'. In 
laboratory and field testing this system performed remarkably well. 

Beginning in 1977 work began on a higher level hazard detec- 
tion system, known as the elevation scanning mast. This system fires 
32 laser pulses at different elevations in each of 32 different azimuths, 
and detects returns using a 20-element linear photodiode array (see 
Figure 1.5). The elevation scanning mast produces about 1000 times 
more data than the previous system and is expected to be much less con- 
servative. 

The elevation scanning mast was completed in 1978. Since 
then attention has been concentrated on making a smooth transition 







Figure 1.5. M.-HD Trlnngulntlon Concept 
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from using the old laser scanning mast to using the elevation 

a 

scanning mast. This involved re-evaluating and redesigning several 
systems. This report deals with two topics. First, an evaluation 
of techniques for upgrading the elevation scanning mast. Second, 
the justification, for, and design of, a new computer /Rover Interface. 


1.2 Introduction to Laser Optics Appraisal 


In 1978 Troiani developed a multi-laser, multi-detector 
(ML/MD) hazard detection concept. This concept requires that the 
laser be aimed at the center of each detector field (see Figure 1.6). 
The result is a quasi-linearized array that enables the inference of 
obstacle heights and slopes. 

Based on computer simulations Troiani found that the ML/MD 
concept required a certain degree of resolution in order to be useful. 
By useful, we are here referring to a particular system's degree of 
conservatism. If a given system's performance is such that it operates 
no less conservatively than the single laser-single detector scheme, 
then it would not be useful. Our objective here is not to take a 
photograph of the terrain, but to accurately detect and avoid obstacles 

Troiani' s simulations reveal that a 15 laser by 20 detector 
system with a 2°/detector field of view was marginally 'useful'. A 
25 laser by 30 detector system with 1.33°/detector field of view 
proved to be better. A 32 laser by 40 detector system looking at 40° 

( 1.0° /detector ) , understandably, yielded even better results. 

The elevation scanning mast is a 32 laser by 20 detector 
system looking at 32° (1.55°/detector) . The position of the mirror 






which directs the 32 laser pulses is monitored by a shaft encoder 
having a resolution of .35°. 

Having less than AO detectors will result in a resolution 
less than indicated by Troiani's simulations using a 32 laser by 40 
detector scheme. The shaft encoder's finite resolution will create 
an accuracy problem. A study of the first consideration led to a 
proposal for increasing the resolution of the elevation scanning mast 
without modifying hardware. A study of the second consideration led 
to the conclusion that nothing should be done about the shaft en- 
coder's .35 resolution at present. 

1.3 The Data Emulator and PRIME/Rover Interface 

In December 1978 a decision was made to begin using the 
Image Processing Laboratory's (IPL's) PRIME 500 computer as the brain 
for the Mars Rover. Up until then a VARIAN 620i had served this pur- 
pose. The decision was made for several reasons. First, the PRIME 
computer would allow the software group to write their artificial in- 
telligence algorithms in FORTRAN. Use of the VARIAN required exten- 
sive knowledge of assembly language. Assembler is cumbersome and 
hard to debug. This switch would simplify the programmer's task. 
Second, by moving to the new machine one would be able to process data 
faster. Higher speed was considered a necessity because of the vast 
increase in data available from the elevation scanning mast. The old 
mast produced one 16 bit word per sweep (see Figure 1.7). The eleva- 
tion scanning mast produces 1024 words per scan. This data must be 
processed quickly, decisions made, and commands sent back to the Rover 
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in order to avert crisis situations. 

After deciding to move software operations to the IPL's 
PRIME computer, the next question was how to interface to this machine. 
Using an AMLC-type Interface did not allow high enough data rates. 

These commonly allow 8.6 Icbaud with the possibility of going to 19.2 
kbaud. Our laser data rates were calculated to be approximately 66.9 
kbaud. It was found that PRIME manufactures a General Purpose Inter- 
face Board (GPIB) that allows 16 bit word transfers with rates as 
high as 1.25 x 10^ words per sec. This would clearly meet our needs. 

As a first step toward building a PRIME/Rover interface it 
was 'decided to construct a Data Emulator. This was to be a multi- 
function device capable of providing multiple word transfers in any 
DMX mode (DMX is a generic term which includes specific processes such 
as DMA, DMC, DMT, DMQ) and Interrupt Requests in the absence of real 
data from the Rover. In addition to this, it must keep track of In- 
terrupt Processing time. This would give us some indication of how 
heavily we were loading the computer. 

The purpose of the Data Emulator was fourfold. First, it 
would provide a test bed for finding out as much as possible about the 
protocol required to interface to the PRIME through the GPIB. Second, 
it would provide information on how heavily our Interrupt Service 
Routine (ISR) was loading the whole system. This information was made 
available by keeping track of Interrupt Processing time. Thirdly, by 
using data flows and interrupts from the Data Emulator, one would be 
able to debug software that was under development. Finally, as the 
PRIME/Rover Interface was being built, the Data Emulator could provide 
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debugging aids without requiring an operating data link from the 
Rover. 

After designing, building and debugging the Data Emulator, 
the next step of designing, building and debugging the complete 
PRIME/Rover Interface was to be a natural, simple step forward. 

The following documentation describes the Data Emulator and the 
PRIME/Rover Interface as designed by the author. 
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LASER OPTICS APPRAISAL 


2.1 The Problem 

Two concerns confronting any scheme for detecting and avoid- 
ing obstacles are those of accuracy and resolution. It is not enough 
to be able to detect an object, one must be able to determine its 
position and describe its extent. This information gives the entity 
seeking to avoid obstables a criterion on which to make decisions. 

The accuracy and resolution with which one is able to do this will 
influence the system's conservativeness. It does little good to have 
one of these features without the other. For example, to know the 
position of an obstacle is meaningless if one's edge detecting reso- 
lution is so poor that one cannot describe the obstacle's extent. 
Likewise, it doesn't help to have high edge detecting resolution if 
some inherent error in the sensing device gives one a poor idea where 
the obstacle is located. 

2 . 2 Resolution 

For a given obstacle pattern, it has been found that the 
motion of an obstacle detecting entity becomes less constrained as the 
resolution of the entity's sensory information increases. Simulations 
done using Troiani's concept demonstrated that as the number of lasers 
and detectors increased, the resolution increased. He found that a 
32 laser by 40 detector system, looking at 40° (1° per detector) pro- 
duced excellent results. Excellent in that the simulated vehicle 
could, with low ambiguity, differentiate between obstacle and non- 
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obstacle terrain. 

The elevation scanning oast has 32 laser per azimuth 
capability* but is equipped with only 20 detectors* each with a 
field of view of 1.55*. The question facing us is* how could this 
system be upgraded to meet Troiani's specifications. There are 
several approaches: 

1. ) Use a second 20 element array identical to the 

one now in use. By concatenating the fields of 
view, one could meet Troiani's specifications. 

2. ) Look for arrays with more elements, If a 40 

element linear photodiode array became avail- 
able it could be used to replace the 20 element 
array now in use. Alternatively one could use 
"Reticon's" 1024 element charge coupled device 
photodiode array. 

3. ) Make the 20 element array look like a 38 element 

array. 

The first approach is being investigated by Jim Odenthal. 
Using two 20 element arrays would be compatible with our system. 

One problem with this approach would be maintaining the proper align- 
ment of the two detectors. This problem would be aggravated when 
the vehicle is tested on real, that is bumpy, terrain. 

At present, the second approach is not being actively pur- 
sued. Forty element linear photodiode arrays seem to be unavailable. 
In addition to this, early experiments with the 'Reticon' 1024 ele- 
ment device indicate that it lacks sufficient sensitivity. Until 
new devices become commercially available, this approach does not 
look feasible. New, higher resolution devices should be investigated 
as they come on the market. 

In the Fall semester of 1978 I was given responsibility 
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for investigating the third approach. There were two different 
techniques for 'tricking' a 20 element array into acting like a 
38 element array. One involved using a highly collimated laser 
beam and is known as the Laser Overlay Concept (LOC) . The other 
Involved using a divergent laser beam and is called the Voting 
Detector Concept (VDC). 

The Laser Overlay Concept requires that Troiani's Laser- 
Detector intersection pattern (Figure 2.1) be modified. The modi- 
fied version is illustrated in Figure 2.2. As indicated by Troiani's 
plan, a series of laser pulses would be aimed at the mid-points of 
each detector field. These are illustrated in Figure 2.2 by 1A, 2A, 
3A, etc. Interleaved between these lasers would be laser shots 
aimed at the intersections of level ground with the edges of each 
detector field. These are labeled IB, 2B, 3B, etc. The laser 

firing sequence would be 1A, IB, 2A, 2B, 3A, 3B Now, how does 

this increase one's resolution? 

Look at the terrain in the illustration. Detector One will 
see Laser 1A. Detector Two will see Laser IB and Laser 2A. Detector 
Three will see Laser 2B only. This has been tabulated below. 

Laser Detector 

1A 1 

IB 2 

2A 2 

2B 3 

By comparing detector responses to the corresponding 'A' and 'B' 
lasers, one's resolution can effectively be doubled. For example, 



Figure 2.1. Troiani ML-MD Triangulation Concept 













Detector One 'sees' Laser 1A. Detector Two 'o^ca' Laser IB. Now, 
assuming the terrain's height does not change radically between 
laser shots (this is considered a reasonable assumption because the 
lateral displacement between laser shots Is approximately 5 cm.) 
one can infer that it lies between level 0 and level 1. The logic 
involved is described as follows. 

'If Detector 1 responds to Laser 1A and Detector 2 re- 
sponds to Laser IB, then terrain is located in Quantum Level 4-1. If 
Detector 1 responds to Laser 1A and Detector 1 responds to Laser IB, 
then terrain lies within Quantum Level -1. Thus, the general logic 
compares the detector responses to Laser nA and Laser nB to assign 
the terrain location. ' ^ 

Locally steep gradients, such as edges of rocks, could in- 
validate our assumption that the terrain's height does not change 
radically between laser shots. These changes would only be important 
if they were severe enough to constitute a hazard. In this case, 
subsequent laser shots will pick out the hazard. 

Realizing the Laser Overlay Concept physically, involves 
creating a highly collimated laser beam. This is the chief drawback 
of this scheme. Designing the optics to create a well collimated 
beam (beam exit diameter, from the collimation optics, on the order 
of 4 mm) from a laser diode stack, is no trivial task. With com- 
mercial units expense becomes the dominant consideration. In addi- 
tion to this, any scheme used to collimate the laser will attenuate 
the signal. This will reduce the effective range of the elevation 
scanning mast. Another drawback has to do with the characteristics 


of the detector array now in use. The detector array is a 20 element 
linear photodiode array. Between each detector is a deadband of 
.05 mm. At a distance of two meters from the detector, taking into 
account the detector optics, one finds that there is a 3 mm deadband 
between detector fields. A highly collimated laser could be lost in 
such a gap. 

The second technique for resolution enhancement known as 
the Voting Detector Concept involves using a diffuse laser beam, 
aimed in the manner Troiani specified. This technique is illustrated 
in Figure 2.3. An explanation of how the resolution is enhanced is 
given below. When Laser 1 fires, only detector 1 'sees' it. When 
Laser 2 fires, detectors 2 and 3 respond. If the terrain is 'seen' 
by only one detector, then one knows that it must be in the zone where 
the laser falls completely within a single detector field. In 
Figure 2.3, height level 0 is such an area. If two detectors 'see' a 
given laser pulse, then the terrain must lie somewhere in the zone 
where the laser is crossing from one detector field to another. In 
Figure 2.3, height level 1 is such an area. Figure 2. A shows how the 
size of height level 0 and height level 1 change as the laser beam 
becomes increasingly collimated. One can see that height level 0 
becomes larger and height level 1 shrinks. In the limit, as the 
collimation increases to the point where the laser beam is a line, 
height level 1 becomes a point and height level 0 becomes as large 
as could be realized in Troiani 's unmodified scheme. If instead of 
increasing the laser's collimation, we decrease it below that shown 
in Figure 2.3, one finds that height level 0 shrinks and height 
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level 1 expands. The optimum collimation is when the laser beam 
covers one-half of a given detector field. In this case height 
levels are roughly equal, and are half as large as the correspond- 
ing levels in Troiani's scheme. It is because of this that the 
resolution throughout the Laser-Detector field has doubled. 

The Voting Detector Concept has a number of advantages 
over the Laser Overlay Concept. First, steep gradients are not a 
consideration in determining the terrain position. Second, it does 
not require sophisticated optics. A single aspheric lens can be 
used to collimate the laser spot to a diameter less than one-half a 
given detector's field of view on level ground. Then by defocusing 
the detector lens one could adjust the laser beam's diameter as seen 
by the detectors to the desired value. Third, this scheme does not 
require that the laser pulse rate be increased over its present 
value. In addition to this, by not attempting sophisticated laser 
collimation one's power output is higher. Thus the range of the 
elevation scanning mast will not be unnecessarily decreased. Finally 
with a broad beam, losing the laser in a deadband would be less 
likely. 

2.3 Accuracy 

As mentioned earlier, the problem of providing adequate 
accuracy is also important when devising obstacle detection sehemes. 
In the new elevation scanning mast the question of providing adequate 
accuracy becomes an important consideration when studying the in- 
fluence of the mirror shaft encoder's finite resolution on data 


interpretation . 


The mirror shaft encoder oh the elevation scanning mast has 
a resolution of .35 degrees. Implementing Trolanl's concept Involves 
aiming the laser directly at the midpoint of a given detector field 
on level ground. Because of the shaft encoder's finite resolution 
this is impossible. One must be satisfied with aiming one's laser 
to within .175 degrees of the correct angle. How does this influence 
one's accuracy? Figure 2.5 shows the theoretical and actual Laser- 
Detector intersection points for a hypothetical system. Based on the 
detector response for the situation illustrated, one would predict the 
terrain to lie between points A and B. In actuality the terrain lies 
between points C and D. It is apparent that if one predicts the 
terrain as lying in a certain band based on the theoretical results, 
one could be wrong. Depending on the extent of this effect, one may 
or may not have a problem. 

Computer simulations done in Fall 1978, ignoring the mirror 
shaft encoder's .35 degree resolution, produced the results tabulated 
in Table 2.1. Simulations done taking into account the shaft en- 
coder's finite resolutions are tabulated in Table 2.2. The results 
in these tables are illustrated in Figure 2.6. Here one sees 
that the .35 degree resolution produces only a 3 cm perturba- 
tion over 2 meters. When viewed in this way the perturbation is 
relatively minor. When viewed as a percentage of the whole level it 
becomes more significant. The Figure reveals that the actual Laser- 
Detector intersection points vary approximately +1.5 centimeters 
over a quantum level which is approximately 10 centimeters wide. The 
error viewed in this way is approximately + 15%. 
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24.15 

92.9 
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88.1 

3.5 

25.20 

97.1 
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92.1 

4.3 

26.25 
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-5.1 

96.0 

5.3 

27.65 

108.4 

-6.9 

102.8 

3.8 

28.70 

112.3 

-5.0 

106.5 

■SHU 

30.10 

119.4 

-6.0 

113.2 

4.6 

31.50 

126.6 

-6.6 

120.0 

4.2 

32.90 

133.8 

-6.8 

126.7 

4.2 

34.30 

140.9 

-6.6 

133.3 

4.6 

35.70 

148.0 

-5.9 

139.9 

5.3 

37.10 

155.0 

-4.9 

146.5 

6.3 

38.85 

166.1 

-6.2 

156.7 

5.5 

40.60 

177.5 

-7.0 

167.0 

HBH 

42.35 

189.0 

-7.4 

177.6 

5.2 

44.10 

200.8 

- 7.2 

188.3 

5.7 

45.85 

212.7 

-6.5 

199.1 

6.8 

47.95 

230.6 

-8.0 

215.0 

6.1 

50.05 

249.5 

-9.0 

231.7 

5.9 


Table 2.2 Laser-Detector intersection points 

including encoder's finite resolution. 



Figure 2.6. Upper and Lower Endpoints for Level Ground 
Quantum Level for a 20 x 20 System. 
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Computer simulations were also done using the Voting De- 
tector Concept ignoring and taking into account the .35 degree en- 
coder resolution. The results are tabulated in Tables 2.3 and 2.4, 
and illustrated in Figures 2.7 and 2.8. In this case the perturba- 
tion over 2 meters is still roughly 3 centimeters. The percentage 
error for a given quantum level jumps to approximately + 30% though 
because the quantum levels are half as large. 

2,4 Conclusion 

In view of the several advantages that the Voting Detector 
Concept has over the Laser Overlay Concept it is my recommendation 
that it be implemented for resolution enhancement. Despite its many 
advantages one should not get the Utopian view that the VDC eliminates 
all one's problems. The existence of a deadband and the detector 
response thresholds ruin the beautiful picture. One must still 
answer questions such as: How much of the laser must fall within a 

given detector field before it is 'seen'? and. How big must the 
laser beam be to bridge the deadband and still be 'seen' by two de- 
tectors? These questions must be answered experimentally before the 
VDC's viability can be fully ascertained. 

The problem of improving the mirror shaft encoder's finite 
resolution was studied in the Fall semester of 1978. The encoder may 
be electronically or mechanically modified to improve its resolution. 
It is my opinion that such modifications are at present unnecessary. 
The inaccuracies inherent in the system when it operates on a real 
terrain will be greater than those due to the shaft encoder's finite 
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Tabla 2.3b Continuation of Table 2.3a. 





































































































































Table 2.4b Continuation of table 2.4a 






































































Figure 2.7. Laser-Detector Intersection Points for Voting 

Detector Concept Ignoring Encoder's Finite Resolution 
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Figure 2.8. Laser-Detector Intersection Po ints for 
Voting Detector Concept Including 
Encoder's Finite Resolution 
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resolution. It would therefore seem wise to do some field testing 
prior to making any modifications to the present system. 


PART 3 


THE DATA EMULATOR AMD PRIME/ROVER INTERFACE 
3.1 The Data Emulator 

The Data Emulator was a test circuit designed as a first step 
toward building a PRIME/Rover Interface. As a test circuit its purpose 
was fourfold: 1) It should serve as a test bed for finding out as 

much as possible about the protocol required to interface to the PRIME 
computer; 2) It should provide information on how heavily our interface 
software (Interrupt Service Routine) loads the computer; 3) It should 
be an aid to debugging software; 4) It should be an aid to debugging 
the PRIME/Rover Interface hardware as it is being built. 

To fulfill the design specifications above, the Data Emulator 
had to be versatile and capable of imitating the proposed interface, at 
lease on a primitive level. A few of the Data Emulator's capabilities 
are listed below. 

1. ) It was capable of transferring two different words in 
any DMX mode. Data words used were switch selectable. Changing from 
one DMX mode to another required some minor hardware modifications. 
Multiple word transfers could be done by altering hardware more signifi- 
cantly. 

2. ) It provided Interrupt Requests in the absence Of any real 
data from the Rover. These came in between the data words transferred. 

3. ) It contained a 'stopwatch' to clock how much time the 
Interrupt Service Routine (ISR) consumed. 

Construction of the Data Emulator was complete by early 
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March 1979. After this it entered a long period of debugging that ex- 
tended over several months. Simple problems with the design, such as 
reversed address lines, were located early. Other problems were 
solved by talking to PRIME by phone. 

After eliminating the simple problems the Data Emulator began 
showing signs of life, but its operation was erratic. It would do any- 
where from one to several thousand Interrupts and then unexplainably 
the computer would undergo a syscrash. This problem went undiagnosed 
fot several months. Finally in early October 1979, with the help of 
Michael Potmesil, it was discovered that the address line tri-states, 
in the portion of the GPIB constructed by PRIME, were flakey. When the 
Data Emulator was the only device using the bus, it operated flawlessly. 
When operated in conditions where time constraints existed, such as 
when the disk was using the bus heavily, the system would fail. Ap- 
parently the tri-states were putting bad address information on the bus. 
After changing tri-states the Data Emulator began to function perfectly. 
After testing the Data Emulator thoroughly, energy was directed toward 
designing and constructing the PRIME/Rover Interface. 

3.2 Operating Principles 

Figure 3.1 shows the relationship of the Data Emulator to the 
whole system. Figure 3.2 is a block diagram of the Data Emulator. 

Within this figure is a counter whose outputs are labeled a, 8 and y. 

It provides the control timing for the Data Emulator. Figure 3.3 shows 
the outputs from the counter, as would be seen on an oscilloscope, were 
the counter not connected to other circuitry. As can be seen, gamma is 
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the MSB. 

The counter's alpha and beta outputs go to the Interrupt and 
DMX control circuitry. These lines determine when Interrupt and DMX 
requests occur* and insure that they do not happen at the same time. 

The beta output also goes to the Mode Line control electronics and to 
the multiplexer which selects which address will 'see' the bus. The 
beta output insures that when an Interrupt is taking place* the In- 
terrupt address is on the address lines well before it is gated to the 
bus. Likewise it insures the Mode lines to be in the Interrupt Mode. 

When doing a DMX transfer* the beta line puts the DMX address on the 
address lines and sets the Mode well before they are gated to the bus. 

The counter does not advance unless the DMX transfer or Interrupt Re- 
quest is finished. The gamma output picks which data word is being 
transferred. 

The Interrupt and DMX control circuitry provides the actual 
Interrupt Requests (UIRQ + ) and DMX Requests (UDRQ+) . It enables the 
counter only after a process is complete. It also controls the Timer. 

The Timer was installed to find out the approximate Interrupt 
processing time. When an Interrupt Request occurred the Timer or stop- 
watch was started. Just prior to leaving the Interrupt Service Routine 
the Timer was stopped and the time read. After this control was trans- 
ferred back to the Data Emulator. The time read was usually on the 
order of 200 microseconds. This number has little significance now. 

The ISR used at the time this was measured will not be used in the 
final interface software. Figure 3.4 shows the Data Emulator's operating 
cycle and Figure 3.5 is a timing diagram for the Data Emulator. Detailed 
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circuit diagrams for this device are in the appendix. 

3.3 The PRIME/Rover Interface 

The primary functions of the PRIME/Rover Interface are as 

follow: 

1. ) To buffer data coming from the Rover via telemetry, such 
that little or no data will be lost. This is accomplished by using a 
bank of First In First Out memory chips (FIFOs). 

2. ) To transfer data into the right location in the computer's 
memory. Data is transferred into PRIME'S memory by requesting a Direct 
Memory Transfer Cycle (DMT cycle). Its location in memory is partly 
specified by the computer &nd partly specified by address information 
coming from the Rover. 

3. ) It must signal the computer after transferring a complete 
block of data, such as an azimuth block, or when something goes wrong. 

In these situations the computer is signalled by an Interrupt Request. A 
status register tells the computer what caused the interrupt. 

4. ) It must be able to output commands back to the Rover. This 
is accomplished by using Programmed Input/Output (PIO) via a U/ART. 

In addition to these primary functions the PRIME/Rover Interface 
has a number of other capabilities, the most important being that hardware 
can be 'data path diagnosed' by running a software package written by 
Michael Potmesil. 

The amount of hardware had to be significantly increased to 
accomplish this, but debugging the Interface was vastly simplified as a 
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result. Tue additional hardware Includes readback circuits on all the 
registers In the Interface. This allowed software to check such things 
as the DMT Address Register, the Command Register, the Vector Address 
and Mode Register, the Slot I.D. Register, and the Status Register. In 
addition to this, circuitry was added to load the FIFO memory banks from 
the computer. This allows software to check both the address and data 
FIFO buffers. In the future, this capability will enable one to check 
the software driver, T$ROVR, without having data coming from the Rover. 

Construction of the PRIME/Rover Interface began in the middle 
of October 1979 and was completed in early November. On November 19 the 
Interface was found to be completely operational. It now has a perma- 
nent slot in the Image Processing Laboratory's PRIME 500 computer. 
Specifications of and complete circuit diagrams for this Interface are 
included in the Appendices. 

3.4 Operating Principles 

Figure 3.6 shows the relationship of the PRIME/Rover Interface 
to the whole system. Data comes from the Royer via telemetry in a serial 
format. Cipolle's electronics parallelizes the data and hands it to the 
PRIME/Rover Interface. The PRIME/Rover Interface then gives the data to 
the PRIME computer. Block diagrams for the Interface are given in 
Figure 3.7, Figure 3.8, and Figure 3.9. To understand how the Interface 
operates one must understand how the PRIME computer handles DMT cycles, 
Interrupt cycles and PIO. For a detailed description of these functions 
refer to the General Purpose Interface User's Guide listed in the 
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DMT Cycle 


When a word has been loaded Into the FIFOs It trickles through 
the FIFOs and the Output Ready (OR) outputs of the FIFOs go high. The 
FIFOs can be loaded by the ADLC or by the computer. When all the FIFO 
OR signals go high then AFOR~ goes low. If the DMT mask is set* UDRQ* 

will go high* following AFOR*. This signals the computer that the user 
is ready to transfer a word of data. When the computer is ready to take 
that word the DENAL" signal is asserted. This gates the address and 
mode Information to the bus. The address tells the computer where we 
want to put the data* the mode tells it that we are interested in a DMT 
transaction. Soon after DENAL” is asserted, the signal MIDST* is 
asserted. This signal gates the data onto the bus, DENAL* and MIDST** 
are NORed to assert the Shift Out (SO) input of the FIFOs. If there is 
no Interrupt pending in the Active Status Register then the FIFOs will be 
free to transfer another word to memory as soon as it becomes available 
at the FIFO outputs. This sequence will continue until an Interrupt 
occurs. 

Interrupt Cycle 

All Interrupts except the Timeout Interrupt are clocked into a 
register by AFOR*. These Interrupts are: 1) End of Scan (EOS); 2) End 

of Azimuth (EOA) ; 3) End of Vehicle Data (EOVD) and 4) FIFO overflow 
(FOFL). The outputs of this register are NORed. This NOR gate is inhibited 
by AFOR" and DENAL". This insures that Interrupts will occur only after a 
given DMT transfer is almost complete. The output of the NOR gate is 
NANDed with the Timeout" signal. The result is an effective OR of all 
five possible Interrupt conditions. The output of the NAND gate is called 


IIRQ + . If it goes high and if the Interrupt Mask is set, then UIRQ + will 
be asserted. This signals the computer that an Interrupt is pending. It 
also resets the DMT mask, preventing any further DMT transactions. In 
addition to this it keeps AFOR + unasserted. The siganl IENAL” gates the 
Interrupt address to the bus. The first instruction in the Interrupt 
Service Routine resets the Interrupt mask by using an OCP instruction. 
Somewhere within the ISR the contents of the Status Register are read. 

The contents of the Status Register will indicate the Interrupt's cause. 
Prior to leaving the ISR the DMT mask is set. After this, DMT transactions 
will resume. A timing diagram showing the DMT and Interrupt timing se- 
quence is given in Figure 3.10. 

PIO Cycle 

The general PIO cycle for the PRIME is illustrated in Figure 
3.11. The Ready signal from the device, our Interface in this case, pro- 
vides the handshake which allows the processor to know what to do next. 

If the Ready signal is asserted the strobe to the device is briefly as- 
serted and the next instructing in software is skipped. If the Ready 
signal is unasserted, the next instruction in software is executed and no 
strobe pulse is issued. 

3. 5 Conclusion 

Development of a reliable PRIME/Rover Interface was hindered 
for several months by flakey address line drivers in the PRIME constructed 
portion of the GPIB. This problem was resolved by replacing 4 I.C.'s. 

After eliminating this problem, work progressed rapidly on the PRIME/Rover 
Interface. This device has been constructed and all tests indicate it is 
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operating as intended. 

Before real data becomes available to the computer, at least 
two things must be done. First, T$ROVR, the I/O driver for the Interface, 
must be completed and debugged. This job is being done by Michael 
Potmesil. Second, the Telemetry link to the Interface must be finished 
and debugged. This work is being done by Dave Cipolle. Having completed 
these two tasks, one should be able to begin testing using the Platform 
designed by Gary Rich. 
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Appendix 5.1 

PRIME/Rover Interface Specifications 
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REGISTER DEFINITIONS 

There are five registers in the user designed portion of the 
Interface. They are listed below. 

1. ) Slot I.D. and Device I.D. Register 

2. ) Command Register 

3. ) DMT/Address Register 

4. ) Status Register 

5. ) Vector Address and Mode Register 


'116X 

'016X 

'146X 

’106X 


’166X 


1.) Slot I.D. and Device I.D. Register (Read Only) 

This Information comes directly from the backplane and from 
the switches that determine the Device Code. This information is 
available to the user by issuing a INA '116X. For a detailed 
description of how this Register is set up, see the following 
figure. 
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2.) Command Register (Read and Write) 

This Register is loaded by issuing a OTA '016X. The top or upper 
eight bits of anything loaded into this Register will be transmitted 
to the Mars Rover • It is also possible to read back any command sent. 
One accomplishes this by issuing a INA ’016X. This enters all 16 bits 
of the Command Register, not just the upper eight bits which are ac- 
tually transmitted to the Rover. The following figure illustrates how 
the Command Register is set up. 
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3.) DMT Address Register (Limited Read and Write) 

One loads this Register by issuing a OTA '146X. At present the 
Register is only 12 bits wide and is equipped to loao only the upper 
12 bits of the 'A' Register. This is configured as it is to provide 
those users doing DMTs some versatility in their choice of how many 
bits of address they will supply. In' the future if one desires to do 
DMAs or DMCs, it can easily be arranged by widening this Register to 
the full 16 bits. 

In our application the top ten bits of this Register will be used 
as DMT address bits. The bottom six bits will come from the Mars Rover. 

-t 

To read back the contents of this Register one must issue a INA '146X. 
The following figure illustrates how the DMT Register is set up. 
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4.) Status Register (Read Only) 

The Status Register's general configuration is illustrated in 
the following figure. Its contents are available for read back 
using a INA '106X. 

The Active Status Register is defined as that portion of the 
Status Register whose bits, when they go high, will produce an In- 
terrupt Request. The Passive Status Register bits will not cause 
an Interrupt Request on going high but instead will give some indi- 
cation of the Interface's Status. A complete list of the Status 
Register bits, showing what they do or indicate about the state of 
the Interface, is given on page 63. 
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STATUS REGISTER 


ACTIVE STATUS REGISTER 

MSB Bit 01 - END OF VEHICLE DATA (EOVD) 

Bit 02 - END OF SCAN (EOS) 

Bit 03 - END OF AZIMUTH (EOA) 

Bit 04 - FIFO OVERFLOW (FOFL) 

Bit 05 - TIMEOUT (TO) 

PASSIVE STATUS REGISTER 
Bit 06 - DIAGNOSTIC MODE ENABLED 

' Bit 07 - BACK OF SCAN 

Bit 08 - AZIMUTH BIT 01 (MSB) 

Bit 09 - AZIMUTH BIT 02 

Bit 10 - AZIMUTH BIT 03 

Bit 11 - AZIMUTH BIT 04 

Bit 12 - AZIMUTH BIT 05 (LSB) 

Bit 13 - COMMAND TAKEN 

Bit 14 - INTERRUPT MASK SET 

Bit 15 - DMx MASK SET 

LSB Bit 16 - TIMEOUT CIRCUIT ENABLED 


5.) Vector Address and Mode Register (Read and Write) 

This Register is loaded by issuing a OTA ' 166X. Read back 

* 

is accomplished by issuing a INA ' 166X. The format for this 
Register is illustrated in the following figure. 
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PROGRAMMING 


Below Is a list of the instruction set implemented by this Interface. 


OTA 

’006X 

Load FIFO Data Buffer 

OTA 

' 016X 

Output to Command Register and U/ART 

OTA 

1 026X 

Load FIFO Address Buffer 

OTA 

’146X 

Load DMT Address 

OTA 

' 166X 

Load Interrupt Vector Address and Mode 

INA 

'016X 

Input Command Sent 

INA 

'106X 

Input Status 

INA 

'116X 

Input Slot I.D. and Device I.D. 

INA 

’146X 

Input DMT Address 

INA 

' 166X 

Input Interrupt Vector Address 

OCP 

’006X 

Clear FIFOs 
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Enable Timeout 
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Disable Timeout 

OCP 

'036X 

Enter Diagnostic Mode 
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Leave Diagnostic Mode 
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Disable DMx 

OCP 
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Set Interrupt Mask 

OCP 

'166X 
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Circuit Diagrams for PRIME/Rover Interface 
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Appendix 5.3 

1 1 Circuit Diagrams for Data Emulator 
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